1. Technical Field
The present invention relates to a checker circuit for checking correct execution of a handshake protocol. The invention also relates to a method for checking correct execution of a handshake protocol.
2. Discussion of Related Art
Handshake protocols are used in asynchronous circuits to organize data transfer between two communication units that communicate asynchronously; the latter are also referred to hereinafter as “CUs”. One group of handshake protocols (“single rail” or “bundled data” protocols) is based on “Request” signals, abbreviated hereinafter to “REQ”, and on “Acknowledge” signals, abbreviated hereinafter to “ACK”. In this group of protocols, a communication channel is provided for the actual data transfer between the communication units. The communication units are additionally connected to each other by two signal lines, with the REQ signal being set and read on one signal line and the ACK signal being set and read on the other signal line in order to control the transfer of data. A respective protocol signal (REQ or ACK) has the meaning of a “flag”, i.e. a kind of Boolean variable that can be either LOW (logic zero) or HIGH (logic one). For example, the REQ signal is set by a first communication unit sending data, and the ACK signal is set by a second communication unit receiving data. The converse is also possible. By means of these protocol signals, the status of data transfer can thus be defined or queried by a communication unit.
When data is transferred in accordance with a handshake protocol from this group, a “push protocol”, the first communication unit sets the REQ signal to HIGH as soon as there are data in the communication channel that are to be transferred from the first communication unit, thus indicating to the second communication unit that data are available to be received. When the data have been successfully received, the second communication unit set the ACK signal to HIGH. The first communication unit, for its turn, acknowledges reception of the ACK signal by deactivating the REQ signal.
Execution of a handshake protocol, also referred to simply as “communication” in the following, may be error-prone. The following are known examples of such errors:                “Stuck at” errors: A protocol signal from a communication unit is permanently LOW or HIGH.        “Premature transition” errors: Two consecutive signal changes (from LOW to HIGH or from HIGH to LOW) are too close together in time, i.e., the time between the two consecutive signal changes is less than the minimum permitted delay δmin.        “Order violation” errors: The order of signal changes does not conform to the order specified by the protocol.        
Errors of the above kinds are obviously detrimental for data transfer between the communication units. It is therefore expedient to check for correct execution of a handshake protocol so that such errors can be detected and the appropriate response to the error type is performed.
A circuit for checking correct execution of a handshake protocol was first presented in 2005 in D. Shang et. al., “On-line testing of globally asynchronous circuits,” Proceedings of the 11th IEEE international On-Line Testing Symposium (IOLTS '05), pp. 135-140, School of EECE, University of Newcastle-upon-Tyne, UK, July 2005. An advancement on this circuit was published in D. Shang et. al., “Low-cost online testing of asynchronous handshakes,” in Proceedings of the Eleventh IEEE European Test Symposium (ETS '06), pp. 225-232, School of EECE, University of Newcastle-upon-Tyne, UK, May 2006.
The checking circuit presented in these two publications and shown schematically in FIG. 1 monitors checker components 11, 12, 13 and 14 for execution of the handshake protocol for two protocol signals (ACK and REQ), in each case with two possible signal changes (from LOW to HIGH, from HIGH to LOW) per signal change (per “phase”). The checker components are connected to each other via monitor circuits 15, 16, 17 and 18. The entire checker circuit thus comprises four checker components and four monitor circuits. The monitor circuits are used for process control and determine which checker component is active, depending on the state of handshake protocol execution.
The checker components of the known circuit each include a delay element, a d-flipflop and a small amount of combinatorial logic. The delay element is used to delay a protocol signal being checked, the value of which is written into the d-flipflop by a signal change in the respective other protocol signal. When the protocol operates free of errors, a logic one that propagates to the nearest monitor circuit and activates the nearest checker component is always stored in the d-flipflop. If the checked signal does not match the value prescribed by the protocol, a logic zero that prevents activation of the nearest checker component is written into the d-flipflop.
The structure of each checker component and monitor circuit is largely identical, except for an input circuit. The delay element integrated in a respective checker component, which may be composed of long inverter chains, for example, occupies a considerable area. Using multiple checker components and monitor circuits in a checker circuit thus involves a considerable area being required by the checker circuit. It is also generally known that the use of many identical components increases the susceptibility to errors and the amount of power required for circuit operation, which is basically disadvantageous. Another disadvantage of known checker circuits is that they are unable to detect any “order violation” errors 20, which arise when the protocol signals have the form shown in FIG. 2.
It is therefore an object of the invention to present a checker circuit for checking execution of a handshake protocol, which can be realized as an integrated circuit that occupies a particularly small area. Another object of the invention is to present a simplified method for checking execution of a handshake protocol.